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Scenario  Report 
Introduction 

Purpose:   The  Center  for  Advanced  Computation  of  the  University  of 

Illinois  at  Urbana-Champaign  is  preparing  a  three  year  research 
plan  to  develop  network  data  management  and  a  resource  sharing 
technology  for  application  in  the  World-Wide  Military  Command 
and  Control  System  (WWMCCS)  Intercomputer  Network  (WIN) .   This 
work  is  supported  by  the  Joint  Technical  Support  Activity  of 
the  Defense  Communications  Agency. 

As  part  of  the  preparation  of  the  research  plan,  scenarios 
were  generated  to  help  expose  potential  problem  areas.   There 
has  been  no  attempt  in  the  scenario  effort  to  solve  the  problems 
discovered  or  to  estimate  research  difficulty  or  potential  pay- 
off.  Where  appropriate,  some  preliminary  research  studies  were 
undertaken  to  estimate  research  difficulty  and  probability  of 
success.   Those  studies  are  separately  documented  in  the  Prelimi- 
nary Research  Study  Report  (CAC  Doc.  No.  162,  JTSA  Doc.  No.  5509). 
Each  of  the  following  scenarios  attempts  to: 

1)  identify  some  of  the  major  research  questions  in  distributed 
data  management 

2)  eliminate  those  design  alternatives  which  are  obviously 
infeasible 

3)  analyze  the  impact  of  the  design  alternatives  not  only 
on  the  technical  considerations  of  network  traffic,  processor 
loads,  storage  requirements,  etc.  but  also  on  the  non-technical 
issues  of  security,  command  authority,  etc. 


It   should  be  emphasized   that   these   scenarios  are   internal 
working  papers.      By  their  very  nature,    it   is  not  possible   to   go 
into  any  great   detail   in  any  one   topic.      These   scenarios  are 
presented   in  the  hope  that   they  will   stimulate  the  same  kinds 
of  discussions   externally  that   they  have  already  done   internally. 
Format :      Each  scenario  will  be  a   terse  discussion  of  a  potential  design 
alternative.      To  aid   the  reader,   a  standard  format   is  adopted. 

Short   title 
Feasibility:      An  overall  assessment  with  capsule  summary  of  reasons  for 

the  judgement 
Design   Issue  Addressed:      Self-explanatory 
Description:     Self-explantory 
Example :     Self-explanatory 
Effects:      a.      Network  traffic 

b.  Processor  loads 

c.  Reliability/ survivability 

d.  Storage  requirements 

e.  Response  time  for  queries 

f.  Ease  of  update 

g.  Security 
Summary :  Self-explantory 

The  scenarios  are  grouped  by  the  design  alternative  studied. 
Within  an  alternative  they  are  ordered  by  increasing  complexity. 
Assumptions :   The  paradigm  for  these  scenarios  is  a  network  of  large 

scale  computer  systems  (hosts)  connected  like  the  PWIN  or  the  ARPA  net- 
work.  A  large  number  of  users  (hundreds)  of  widely  varying  levels  of 
computer  familiarity  are  working  on-line  to  the  various  hosts.   The 
dominant  work  activity  is  some  task  which  requires  access  to  the  data 
bases  provided  by  the  hosts.   Some  of  these  data  bases  are  distributed, 


that  is,  no  single  host  contains  all  the  segments  of  the  data  base.   We 
shall  focus  exclusively  on  the  distributed  data  bases,  and  will  omit  the 
"distributed"  for  brevity.   Two  generic  user  activities  can  occur: 
inquiry  and  update.   Each  of  these  generic  types  affects  network  traffic 
in  different  ways. 

An  inquiry  is  input  to  the  host  to  which  the  user  is  connected. 
The  data  base  is  searched  and  the  data  relevant  to  the  user's  inquiry 
is  returned  to  the  person.   Two  types  of  network  traffic  may  result  from 
inquiries.   The  first  is  the  transmission  of  the  inquiry  to  remote  hosts 
when  needed  segments  of  the  data  base  are  not  locally  available.   The 
second  is  the  reply  information  from  these  remote  hosts. 

An  update  differs  from  an  inquiry  in  that  updates  modify  the  data 
base  and  inquiries  do  not.   Hence  inquiries  need  only  be  directed  to  a 
single  copy  of  a  data  base  while  updates  must  be  reflected  in  all  copies 
of  a  data  base. 

A  basic  assumption  which  is  manifest  in  many  of  the  scenarios 
is  that  communication  exchanges  via  the  network  require  on  the  order  of 
tenths  of  seconds  to  complete.   Thus,  many  operations  which  are  acceptable 
when  communication  between  processes  requires  microseconds  (i.e.  via 
shared  memory)  become  totally  impossible  when  the  required  communication 
takes  three  or  four  orders  of  magnitude  more  time  to  complete. 
Organization:   The  seven  scenarios  of  this  report  may  be  divided  into 
two  classes  by  the  topic  addressed: 

1)  allocation  and  role  of  data  base  segments 

a.  single  copy 

b.  single  copy  with  remote  passive  backup 

c.  single  copy  with  remote  active  backup 

d.  multiple  primary  copies 


2)  techniques  for  data  security 

a.  all  security  checks  performed  locally 

b.  all  security  checks  performed  at  host  where  the  segment 
is  located 

c.  security  checks  performed  both  locally  and  at  the  host 
where  the  segment  is  resident 


Single  Copy  of  Each  Data  Segment 

Feasibility:   FEASIBLE,  current  operating  mode.   (Where  all  segments  are 
located  at  a  single  host,  the  distributed  data  base  becomes  a  simple, 
remotely  accessible  data  base.) 

Design  Issues  Addressed:   Segment  allocation. 

Description:   A  single  copy  of  each  segment  is  maintained,  different 

segments  may  be  resident  at  different  hosts.   Inquiries  and  updates 
are  directed  towards  the  appropriate  segment  using  the  network  if  the 
segment  is  not  locally  available. 

Example:  A  network-wide,  distributed  FORSTAT  data  base  exists.   Each 

host  physically  has  the  segments  of  the  data  base  for  which  the  command 
is  functionally  responsible.  When  information  not  available  locally  is 
requested  by  a  user,  the  network  is  used  to  transmit  the  query  to  other 
sites.  For  example,  a  user  at  LANTCOM  may  request  information  from  MAC 
about  airlift  capability.  Because  hosts  represent  functional  areas, 
most  updates  would  originate  at  the  host  where  the  segment  is  located. 
Thus,  most  updates  for  a  MAC  segment  will  originate  within  MAC. 


Inquiries  - 


Updates 


Figure  1.   Single  copy 


Effects:   a.   Network  traffic.   In  a  PWIN/WIN  environment  it  is  heavily 
application  dependent  whether  or  not  update  (or  inquiry)  traffic 
will  add  to  the  network  load.   For  some  applications,  all  the  updates 
are  transmitted  via  the  network;  for  others,  none  are.   This  repre- 
sents an  important  measurement  area.   Inquiries  must  be  directed  to 
the  host  with  the  appropriate  segment  via  the  network. 

b.  Processor  loads.   For  segments  which  are  "popular,"  a 
large  portion  of  the  processor  load  for  that  segment  may  be  exter- 
nally imposed.   In  general,  the  total  amount  of  processing  is  not 
much  greater  than  the  case  where  a  non-distributed  data  base  is 
remotely  accessed.   A  slight  increase  occurs  over  a  simple  remotely 
accessed  data  base  because  the  querying  host  may  have  to  do  some 
directory  processing  to  determine  where  a  given  segment  is. 

c.  Reliability.   Since  only  one  copy  of  a  given  segment  is 
maintained,  reliability  is  low.   The  loss  of  that  host  would  make 
the  segment  unavailable  to  any  user . 

d.  Storage  requirements.   The  single  copy  alternative  requires 
the  minimum  storage  for  data  segments.   There  is  an  increase  in  the 
storage  needed  for  directories  over  a  simple  remotely  accessed 

data  base  because  the  directory  must  include  host  location  of  the 
segments. 

e.  Response  time  for  queries.   Response  is  limited  by  two 
factors,  network  latency  and  segment  owner  host  processing.   Since 
a  remote  query  must  pass  through  the  network,  it  incurs  any  network 
delays,  such  as  delays  in  the  orginating  host,  the  communication 
subnet,  and  the  receiving  host.   The  processing  of  the  query  can 
occur  on  only  one  host,  and  is  thus  limited  by  the  load  on  that 


host.   If  other  processing  has  higher  priority,  the  query  cannot 
be  farmed  out  to  a  less  busy  host. 

f.  Ease  of  update.   Update  is  nearly  identical  to  that  which 
occurs  in  a  simple,  remotely  accessed  data  base. 

g.  Security.   Because  the  data  base  is  distributed,  the  input 
to  the  security  decision-making  process  must  also  be  distributed. 
It  would  seem  unreasonable,  for  example,  to  expect  that  LANTCOM 
would  maintain  security  profile  information  (clearances,  special 
access  caveats,  etc.)  for  every  possible  user  of  the  LANTCOM-owned 
segments.   It  is  equally  unreasonable  to  expect  that  LANTCOM  would 
allow  a  remote  user  unrestricted  access.  An  important  area  of 
research  is  the  mechanization  of  security  controls  in  distributed 
data  base  management.   (The  security  scenarios  elaborate  upon 
these  points.)   The  single  segment  copy  design  alternative  does 
help  the  situation.   The  sensitive  information  is  available  in 
only  one  location.   In  the  PWTN/WIN  environment  that  location  is 
likely  to  be  the  organization  with  command  responsibilities  over 
the  data,  and  is  thus  in  a  favorable  position  to  make  access  control 
decisions. 

immary :   This  is  what  typically  is  envisioned  when  a  distributed  data 
base  is  proposed.   It  allows  the  distributed  data  base  to  be  viewed 
as  a  more  conventional  data  base  in  which  some  of  the  segments  are 
stored  on  a  network  virtual  peripheral.   That  is,  the  segments  are 
actually  located  on  another  host,  and  are  accessible  via  the  net- 
work.  Some  theoretical  work  has  been  done  on  the  problem  of  where 
to  locate  a  data  base  segment  in  a  network,  but  the  realities  of 
the  PWIN/WIN  environment  may  impose  constraints  which  preclude 


technically  optimal  allocation  strategies.   The  single  copy  scheme 
offers  reasonably  easy  management  of  the  distributed  data  base, 
but  has  poor  reliability. 


Single  Primary  Copy  with  Passive  Backup  Copies 
(Remote  Journalling) 

Feasibility:   FEASIBLE,  but  network  traffic  increases. 

Design  Issues  Addressed:   Segment  allocation. 

Description:   The  basic  mechanism  is  the  single  segment  copy  scheme.   To 
improve  data  base  reliability  and  survivability,  a  journal  of  update 
transactions  to  the  primary  segment  is  kept  at  one  or  more  remote  hosts 
along  with  an  old  copy  of  the  segment.   The  journal  information  is  sent 
via  the  network.   In  the  event  of  loss  of  the  primary  segment  (or  host), 
the  remote  journal  is  processed  on  the  old  copy  to  create  a  new  primary 
copy. 

Example:   A  segment  owned  by  REDCOM  is  backed  up  by  a  remote  journal 
stored  at  SAC.   Minimal  processing  of  the  remote  journal  occurs. 
Periodically  an  up-to-date  copy  of  the  data  base  segment  from  REDCOM, 
incorporating  previously  journalled  information,  is  obtained  and  the 
journalling  process  is  restarted. 


Inquiries 


Updates 


Figure  2.   Single  copy  with  passive  backup 


Effects:   a.   Network  traffic.   An  additional  message  is  generated  for 
each  remote  journal  by  each  update.   If  the  potential  loss  of  the 
most  recent  updates  can  be  tolerated,  updates  may  be  collected 
together  and  shipped  in  a  larger  unit,  improving  the  network  through- 
put.  Inquiry  traffic  remains  the  same  as  the  single  copy  case. 

b.  Processor  loads.   Some  additional  load  is  imposed  on  the 
processors  keeping  remote  journals.   In  the  event  of  loss  of  the 
primary  copy,  a  remote  host  will  become  the  designated  temporary 
owner  for  the  duration  of  the  loss.   The  data  base  segment  must 
first  be  regenerated,  and  then  the  inquiry  and  update  loads  for 
the  segment  must  be  accepted.   A  decision  may  have  to  be  made 
about  the  importance  of  this  new  workload  relative  to  the  normal 
site  workload. 

c.  Reliability.   Remote  journalling  is,  in  reality,  a  sophis- 
ticated form  of  off-site  backup.   It  offers  impressive  gains  in 
reliability  at  low  cost.   If  the  backup  copy  is  very  old  and  the 
backup  processor  is  heavily  loaded,  there  may  be  a  period  of  up 

to  several  hours  when  the  segment  will  be  unavailable  because  it 
is  being  regenerated. 

d.  Storage  requirements.   The  remote  journal  will  be  small. 
For  example,  CINCPAC  indicated  less  than  5%  change  per  cycle  of 
their  40  million  byte  FORSTAT  data  base  or  less  than  2  million 
bytes  per  cycle.   Also,  many  of  these  changes  are  to  highly  vola- 
tile items  like  ship  movement  information.   Thus,  a  copy  of  the 
data  base  and  a  week  of  updates  could  be  stored  on  about  5  reels 
of  tape  or  about  half  a  DSS  190  disk. 

e.  Response  time  for  queries.   Unchanged  over  single  copy. 
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f.  Ease  of  update.   The  only  change  over  the  single  copy 
case  is  that  a  remote  journal  entry  must  be  created.   Since  jour- 
nalling  is  normally  done  locally  anyway,  this  would  seem  to  impose 
a  minor  added  task. 

g.  Security.   Security  may  potentially  be  more  compromised 
over  the  single  copy  case  because  the  capability  exists  to  create 
a  duplicate  of  the  data  base  at  the  remote  journal  site.   This 
could  be  prevented  by  the  application  of  a  privacy  transformation 
(encryption)  to  the  remote  journal,  with  the  key  available  only 
in  an  emergency,  i.e.,  when  the  segment  must  be  regenerated.   The 
subject  of  privacy  transformations  on  data  bases  is  a  potentially 
fruitful  area  of  research,  particularly  if  it  is  combined  with 
file  compression  techniques. 

Another  security  consideration  is  that  in  the  event  that 
the  segment  must  be  regenerated,  the  user  profile  data  at  the 
original  host  site  will  be  needed  for  security  decisions  at  the 
new  host.   If  this  is  not  done,  the  regenerated  copy  will  either 
be  unusable  (because  no  user  has  authorization  to  access  it)  or 
unprotected  (because  no  user  is  denied  access  to  it) .   It  would 
seem  to  be  another  research  area  to  study  mechanisms  for  achieving 
an  orderly  transition  from  primary  to  regenerated  backup  copy. 
Summary :   For  data  base  segments  whose  loss  can  be  tolerated  for  a 
limited  but  not  indefinite  time,  remote  journalling  seems  to 
provide  a  reasonable  alternative. 
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Single  Primary  Copy  with  Active  Backup  Copies 
(Running  Spares) 

Feasibility;   FEASIBLE,  but  network  traffic  and  prime  time  remote  processor 
loading  increase. 

Design  Issues  Addressed:   Segment  allocation. 

Description:   A  given  segment  is  duplicated  at  each  of  a  number  of  hosts. 
One  host  is  designated  the  primary  host  and  is  responsible  for  the 
synchronization  and  propagation  of  updates  to  each  of  the  secondary 
copies.   A  major  research  topic  is  the  control  of  inquiry  traffic,  i.e., 
who  decides  which  copy  will  be  queried. 

Example:   A  segment  which  is  owned  by  LANTCOM  is  duplicated  at  REDCOM.   All 

update  traffic  is  directed  to  LANTCOM,  which  is  responsible  for  propagating 
it  to  the  backup  copy.   The  REDCOM  host  is  responsible  for  keeping  up  with 
the  updates  so  its  copy  remains  current.   Two  basic  alternatives  exist  for 
inquiry  traffic.   The  first  is  to  send  all  inquiries  to  LANTCOM  for  pro- 
cessing (central  management) .   LANTCOM  would  then  decide  whether  to  do 
the  processing  itself  or  farm  the  work  out  to  REDCOM.   A  second  choice 
is  to  simply  route  the  inquiry  to  any  host  with  a  copy  (distributed 
management).   In  the  case  where  every  host  has  a  copy  of  a  given  segment, 
no  network  traffic  at  all  would  be  generated  from  inquiries,  although  the 
update  traffic  load  increases. 
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Inquiries 


Updates 


Inquiry 
Replies 


a.   Central  inquiry  management 


Inquiries 
Updates 


b.   Distributed  inquiry  management 
Figure  3.   Single  copy  with  active  backup 
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Effects:   a.   Network  traffic.   As  discussed  above,  the  network  traffic 
is  a  function  of  the  number  of  updates,  the  number  of  queries  and 
the  number  and  location  of  secondary  copies.   An  important  component 
of  any  distributed  data  base  model  will  be  estimators  for  network 
traffic  in  running  spare  configurations. 

b.  Processor  loads.   The  network-wide  processing  load  for 
maintaining  the  data  base  is,  approximately,  the  single  site  load 
multiplied  by  the  number  of  copies.   This  occurs  because  each  copy 
must  be  updated  along  with  the  primary  copy.   Such  processing  may 
be  partially  reduced  by  doing  as  much  of  it  as  possible  at  the  pri- 
mary host,  and  sending  out  the  updates  partially  processed.   While 
passive  backups  can  be  updated  on  low  use  shifts,  active  backups 
require  immediate  processing  and  impact  prime  shift  loads. 

c.  Reliability.   Running  spares  provide  an  immediate  backup 
capability  should  the  primary  host  become  unavailable.   Of  course, 
care  must  be  taken  that  the  transition  from  primary  to  secondary 
is  an  orderly  one.   As  mentioned  previously,  this  transition  is  an 
important  research  area. 

d.  Storage  requirements.   The  storage  required  is  multiplied 
by  the  number  of  copies  maintained. 

e.  Response  time  for  queries.   Response  can  improve  or  degrade 
over  previous  scenarios.   If  a  heavily  loaded  site  passes  off  an 
inquiry  to  a  lightly  loaded  site,  then  the  response  can  improve.   If, 
however,  a  lightly  loaded  site  passes  off  to  another  site,  then  response 
will  always  degrade  due  to  additional  network  transit  time.   Serious 
degradation  can  occur  if  the  receiving  site  is  more  heavily  loaded 

than  the  site  passing  off.   The  distributed  inquiry  management 
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scheme  (transmit  the  inquiry  directly  to  the  most  responsive/avail- 
able processor)  may  improve  the  overall  response  times,  since  several 
processors  will  be  sharing  the  inquiry  load.   Research  is  needed  in 
this  area. 

f.  Ease  of  update.   Updates  remain  fairly  simple  because  the 
owner  host  has  all  the  synchronization  responsibilities  and  can 
present  a  well-defined  sequence  of  updates  to  the  backup  copies. 

g.  Security.   There  is  a  serious  degradation  in  security 
because  several  up-to-date  copies  of  the  data  base  exist,  and  the 
potential  penetrator  has  a  choice  of  sites.   Care  must  be  taken 
at  the  backup  sites  to  assure  that  the  security  standards  of  the 
primary  copy  are  maintained.   The  replication  of  user  profiles 
discussed  above  continues  to  be  required  for  orderly  transition 
from  primary  to  backup  copy  in  the  event  of  loss  of  the  primary. 

Summary :   For  those  segments  whose  unavailability  cannot  be  tolerated, 
the  running  spares  idea  may  be  the  only  acceptable  alternative. 
Depending  upon  the  update/ inquiry  mix,  the  overall  network  traffic 
may  actually  be  reduced  over  other  schemes.   This  can  occur  because 
inquiries  directed  at  hosts  with  a  copy  do  not  generate  spurious 
network  traffic.   A  thorough  analysis  of  the  costs  and  benefits  of 
this  design  alternative  is  warranted. 


15 


Multiple  Primary  Copies  of  Data  Segments 

Feasibility:   FEASIBLE,  but  expensive  and  difficult  due  to  the  necessity 
for  synchronization.   The  running  spares  scheme  appears  equal  or 
superior  in  every  situation. 

Design  Issue  Addressed:   Segment  allocation. 

Description:   Multiple  primary  copies  are  maintained.   Both  inquiries 
and  updates  may  be  directed  to  any  copy.   Updates  are  coordinated 
via  the  network  with  other  copies  of  the  segment.   No  single  host 
controls  the  updating. 

Example :   A  data  base  segment  is  maintained  both  by  PACOM  and  NMCSSC. 
Inquiries  and  updates  are  accepted  by  either  host .   The  updates 
accepted  by  one  host  must  be  coordinated  with  the  other  host. 


Inquiries 
Updates 


Inquiries 


Updates 


Updates, 
Synchronization 


Figure  4.   Multiple  primary  copies 
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I fects:   a.   Network  traffic.   Inquiry  traffic  load  is  the  same  as 

in  the  running  spares  scheme.   Because  updates  must  be  synchronized 
between  all  copies,  network  traffic  relating  to  updates  is  sub- 
stantially increased. 

b.  Processor  loads.   The  processor  loads  are  the  same  as 
the  running  spares  situation  plus  an  additional  load  due  to  the 
synchronization  of  updates  on  multiple  copies. 

c.  Reliability.   Reliability  is  equal  to  the  running  spares 
scheme. 

d.  Storage  requirements.   The  same  amount  of  storage  is 
required  as  in  the  running  spares  situation. 

e.  Response  time  for  queries.   Query  response  may  be 
substantially  degraded  over  the  running  spares  situation  due  to 
synchronization  delays  for  updates.   In  general,  inquiries  are 
not  permitted  to  proceed  until  the  updates  for  the  segment  are 
completed.   If  this  is  not  done,  a  partially  completed  update 
may  have  left  the  segment  in  an  unusable  state.   In  the  multiple 
primary  copy  case,  synchronization  takes  longer  than  in  the  running 
spares  case.   Thus,  updates  will  take  longer  to  complete  and  seg- 
ments will  spend  more  time  locked  against  inquiry,  degrading 
response  time. 

f .  Ease  of  update.   Updates  are  more  complex  in  the  multiple 
primary  copy  situation  because  they  must  be  synchronized  among  all 
the  copies.   This  will  likely  require  several  network  messages  to 
be  exchanged.   In  typical  network  environments  this  exchange  of 
messages  may  require  several  seconds  to  complete.   If  the  synchroni- 
zation is  ignored,  the  copies  of  the  data  base  will  become  more  and 
more  dissimilar.   Consider  what  happens  if  two  users  (user  A  and 
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user  B)  both  attempt  to  update  the  same  record.  If  user  A  wants 
to  set  field  X  to  10,  and  user  B  wants  to  set  X  to  12,  we  must  be 
sure  that  the  updates  are  synchronized  for  all  copies  of  the  seg- 
ment. The  updates  must  be  done  in  precisely  the  same  order  at  all 
copies,  or  X  will  have  different  values  for  each  copy  (10  in  some 
copies  and  12  in  others) .  The  efficient  synchronization  of  multi- 
ple hosts  is  a  research  question. 

g.   Security.   Since  no  single  host  is  in  control,  major 
security  problems  arise  that  are  of  the  same  nature  as  those  of 
distributed  inquiry  management  in  the  running  spares  situation. 
Specifically,  it  may  be  hard  to  enforce  the  same  security  con- 
straints at  every  copy. 
Summary :   The  multiple  primary  copy  scheme  is  harder  to  manage  and  has 

greater  processor  loads,  greater  network  traffic,  and  slower  response 
time  than  the  other  schemes  considered.   For  the  alternatives  con- 
sidered, it  appears  to  offer  no  advantage  over  the  single  primary 
with  active  backup  (running  spares)  scheme  in  reliability,  storage, 
security,  or  command  prerogatives.   Hence,  multiple  primary  copies 
does  not  appear  to  be  a  viable  design  alternative. 
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Local-only  Security 

Feasibility:   Not  clear.   Requires  trust  by  remote  host  of  local  validation 
and  authentication  of  user  requests. 

Design  Issue  Addressed:   Security. 

Description:  Validation  of  a  user  request  occurs  only  at  the  local  host 
servicing  the  user.   When  the  user  accesses  a  remote  segment,  the 
remote  host  assumes  that  the  request  has  already  been  validated. 

Example:   A  user  logs  on  to  the  host  at  LANTCOM  and  issues  commands  which 
cause  a  data  base  segment  at  MAC  to  be  accessed.   The  MAC  data 
management  system  assumes  that  the  LANTCOM  data  management  system 
has  validated  the  request  and  MAC  performs  only  limited  authenti- 
cation on  it. 

Effects:   a.   Network  traffic.   Since  a  host  maintains  little  security 
information  about  its  remote  users,  hardly  any  network  traffic 
is  required  to  update  the  remote  security  information. 

b.  Processor  use.   There  is  minimum  processor  use  because  a 
user  request  is  checked  only  once,  at  its  origination. 

c.  Reliability.   Because  only  the  local  host  has  the  security 
data  base,  even  if  a  user  can  get  onto  the  network  in  some  way 
which  bypasses  his  failed  local  host,  he  may  not  be  able  to  access 
anything.   Thus,  reliability  is  low. 

d.  Storage  requirements.   This  represents  the  minimum  storage 
for  security-related  data. 

e.  Response  time  for  queries.   Not  applicable. 

f .  Ease  of  update.   Since  only  a  single  copy  of  the  security 
data  is  maintained,  it  is  relatively  easy  to  update. 
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g.   Security.   In  order  to  provide  even  the  most  basic 
security,  the  logical  link  to  access  the  remote  data  base  must 
be  a  protected  entity.   If  this  is  not  done,  a  process  may  be 
able  to  masquerade  as  the  local  data  base  management  system  (dbms) . 
The  remote  process  would  have  no  way  of  knowing  to  whom  it  was 
talking  -  a  real  data  base  management  system  which  is  indeed  doing 
the  authentication  and  validation  assumed,  or  a  process  masquerading 
as  the  dbms  and  doing  no  authentication  or  validation.   Implicit 
in  this  discussion  is  the  assumption  that  the  local  dbms  knows 
enough  to  make  security  decisions  about  remote  data. 
Summary :   This  design  perhaps  offers  the  lowest  cost  meaningful  security 
system  because  it  does  not  duplicate  any  security  information. 
There  is  some  question  about  whether  or  not  it  is  possible  to 
operate  a  "pure"  version  of  this  design,  since  the  local  authenti- 
cation and  validation  procedures  must  have  a  great  deal  of  know- 
ledge of  the  remote  data  resources  in  order  to  make  content-sensitive 
security  decisions.   It  is  also  not  clear  whether  any  existing 
operating  system  is  secure  enough  to  warrant  the  expenditure  of 
scarce  resources  in  pursuit  of  the  more  difficult  goal  of  data 
base  management  system  security. 
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Remote-Only  Security 

Feasibility:   Not  clear.   Requires  extensive  maintenance  of  remote 
security  related  data  bases  that  may  be  used  very  infrequently. 

Design  Issue  Addressed:   Security. 

Description:   Validation  of  a  user  request  occurs  at  the  host  answering 
it,  whether  local  or  remote. 

Example :   A  user  at  LANTCOM  issues  requests  for  information.   For  those 
which  can  be  answered  locally,  the  LANTCOM  host  does  all  the 
validation  of  the  request.   For  those  requests  which  access  remote 
data,  the  LANTCOM  host  performs  minimal  security  related  work.   The 
request  is  passed  on  almost  unchecked  to  the  remote  host.   There, 
the  validation  is  performed  in  a  manner  almost  identical  to  that 
which  occurs  for  a  request  local  to  that  host. 

Effects:   The  effects  are  almost  identical  to  those  encountered  in  the 
use  of  running  spares  (one  primary  copy  of  a  segment  with  multiple 
backup  copies) .   The  host  where  the  user  is  local  (most  likely  his 
command)  has  the  responsibility  of  maintaining  the  security  data 
at  the  other  hosts  of  the  network. 

Summary :   This  approach  is  quite  attractive  from  a  theoretical  stand- 
point.  There  are  no  "back  doors"  into  the  data  base.  All  requests 
receive  similar  validation  whether  they  originated  locally  or 
remotely.   The  major  problem  with  a  "pure"  implementation  of  this 
approach  is  that  the  security  data  must  be  kept  up-to-date  at  all 
the  remote  sites.   It  may  be  possible  to  mollify  these  objections 
by  allowing  some  compromise  between  local-only  and  remote-only 
security,  such  as  that  outlined  in  the  next  scenario. 
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Send-Ahead  Security 

Feasibility:   Probably  feasible,  this  approach  is  analogous  to  the 
practice  of  sending  clearance  information  ahead  of  a  visit. 

Design  Issue  Addressed:   Security. 

Description:   Before  a  user  may  access  a  remote  data  base  segment  his 
clearances  must  be  sent  to  the  remote  host.   From  then  on  the 
system  proceeds  in  a  manner  similar  to  the  remote-only  security 
scenario. 

Example :   It  is  determined  that  a  REDCOM  user  needs  to  have  access  to 
LANTCOM  data.   The  security  information  about  the  user  is  sent 
from  REDCOM  to  LANTCOM  in  advance  of  any  activity  by  the  user. 
The  approximate  duration  of  the  activity  at  LANTCOM  is  known, 
and  during  that  time  the  LANTCOM  security  data  base  is  updated 
to  reflect  any  changes  in  the  user's  status. 

Effects:   a.   Network  traffic.   The  level  of  network  traffic  required 
to  support  send-ahead  security  is  between  the  levels  required  to 
support  remote-only  and  local-only  security.   In  addition,  the 
level  of  traffic  is  better  related  to  the  real  needs  of  the 
community,  in  that  only  users  who  are  active  at  remote  sites 
need  to  have  up-to-date  security  data  there. 

b.  Processor  loads.   Analogous  to  effects  on  network  traffic, 

c.  Reliability.  Reliability  is  also  intermediate  between 
the  local-only  and  remote-only  cases.  If  a  user  can  get  on  the 
network  while  by-passing  a  failed  local  host,  he  will  be  able 

to  access  the  remote  segments  only  if  he  has  previously  sent-ahead 
his  clearances. 
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d.  Storage  requirements.   Analogous  to  effects  on  network 
traffic. 

e.  Response  time  for  queries.   Not  applicable. 

f.  Ease  of  update.   The  update  problem  is  complicated  some- 
what by  the  necessity  of  determining  whether  (and  to  whom)  security 
updates  should  be  sent . 

g.  Security.  If  the  means  by  which  security  information  is 
transmitted  and  maintained  is  suitably  protected,  the  security  of 
the  send-ahead  approach  can  be  equivalent  to  the  remote-only  case. 

Summary :   Send-ahead  should  be  studied  further  as  a  reasonable  approach 
to  providing  security  in  a  distributed  environment.   It  retains 
the  features  of  pre-computer  network  operations,  which  is  a  desirable 
goal  for  the  near  term.   Note  that  the  only  difference  between 
remote-only  and  send-ahead  security  is  that,  in  the  latter  scheme, 
data  is  kept  at  remote  sites  only  for  users  who  are  now  or  soon 
will  be  active  there.   Finally,  it  should  be  again  emphasized 
that  these  security  scenarios  represent  only  a  small,  but  critical, 
part  of  the  total  security  question.   Substantial  research  is 
needed  in  this  area. 
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